Multimedia data protection

ABSTRACT

A method of transmitting a media work such as a movie to a client is disclosed. The method includes (a) encrypting the work using a sequence of different keys corresponding to respective temporally spaced segments of the document, (b) transmitting software code containing an algorithm from a security server to the client, the algorithm having a result that is a function of the state of the client, (c) executing the code at the client and returning the result to the security server, (d) determining whether the result is indicative of an unmodified client. The method further includes (e) transmitting a segment from a server to the client, (f) securely streaming a key corresponding to the transmitted segment from a secure remote server to the client, (g) decrypting the segment using the obtained media key, (h) if step (d) indicates a modified client, preventing further keys from being transmitted, otherwise repeating steps (e) to (g) and repeating steps (b) to (d).

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.11/995,677, filed Aug. 7, 2008, entitled “Multimedia Data Protection”,which is a national phase entry of PCT/GB2006/002619, filed Jul. 14,2006, designating the United States of America and published in theEnglish language, which claims priority to Application No. GB 0514492.8,filed Jul. 14, 2005. The disclosures of the above-referencedapplications are hereby expressly incorporated by reference in theirentireties.

BACKGROUND

1. Field

The present invention relates to the secure distribution of multi-mediaworks that have a temporal dimension such as movies, TV shows, audiodocuments, etc. In particular, it relates to a system for securelydelivering such works to a user in a manner that prevents the user fromobtaining an unauthorized copy of the work. Aspects of the inventionalso have applications in other server-client situations such as on-linebanking, gaming, etc.

2. Description of the Related Technology

Illicit copying of artistic works is a perennial problem. In the earlydays of the movie industry, whilst it was possible for unauthorizedcopies of films to be made, it was expensive to do so and notpracticable except for persons with access to specialist equipment. Withthe advent of home video recorders a new market for movies and otherrecorded programmes became available to producers whilst simultaneouslyit became possible for those recordings to be illicitly copied anddistributed.

Today the DVD format, which provides higher quality playback and a moreconvenient and compact data carrier, is rapidly supplanting the video.In addition, with the advent of affordable broadband Internetconnections, there is now an emerging market for downloading orstreaming movies and other media from remote servers onto homecomputers.

Where a media work is downloaded, a copy of it is stored on the harddrive of the computer and it can normally be viewed repeatedly by theuser, analogously to watching a video recording. Streaming content,whether live or recorded, is watched as it is transmitted to thecomputer (as with a conventional TV programme) in almost real-time(there is a short delay due to the need to provide some buffering). Itis well known for radio and some TV stations to offer their content inthis manner.

Whilst these improvements in technology have allowed the development ofa promising new market for media companies, there is also acorresponding problem in preventing the production and distribution ofunauthorized copies of the works. It now is commonplace for evenlow-cost home computers to have the capability to record content ontoDVDs.

Techniques have therefore been developed with the aim of preventing suchcopying. In a conventional approach, the media supplier, who is referredto here as a “content provider”, owns encoded media works, for examplemovies, which will be referred to generically as “media works”. Theseare to be distributed and presented to a user's client program/viewer ina way that does not allow the user to create a copy of the encoded mediawork. The delivery can be carried out by either streaming over a networkor by delivering a physical medium, for example a DVD, to the client.

Where the work is transported over a network it is usually secured bycryptographic means to protect the work from being intercepted andcopied by a third party. We refer to these cryptographic means as“transport encryption”. (Encryption, which is a security measure, is tobe distinguished from encoding, whereby the work is converted andusually compressed into a form that can readily and efficiently betransmitted.) Encryption techniques are sufficiently well developed andsecure that the communication over computer networks can be secured inan appropriate way.

Before the media work is delivered to the client, the content ownerprotects the encoded media document using cryptographic means. Within asecure “provider environment”, an encryption tool is used to encrypt thework with a “media key” to create an encrypted encoded media work, the“encrypted work”.

The intention is that the client can then only use the work if he hasthe media key that allows him to decrypt it. This can be embedded in theclient program/viewer/player and/or the media, for example inDVD-players and DVDs. (The client program/viewer/player may be afree-standing device or a viewer software program on a computer.)

Another option, which is illustrated schematically in FIG. 1, is for themedia key to be retrieved from a license server 1 on demand. This allowsfor streaming of the media work. To support this model, the encryptiontool 2 wraps the media key, together with additional information, in alicense 3 and sends this to the license server 1. The client thenreceives an encrypted, encoded media stream 4 from the streaming server5 that has to be decrypted in a viewer 6 before it can be presented tothe client. In order to watch the encrypted movie 7, the viewer requestsa license containing the media key from the license server (see“Start-up Phase” in FIG. 1).

Once the viewer has received the license 3 (and therefore the mediakey), it connects to the streaming server 5 from which it receives anencrypted encoded media stream 4. The viewer uses the media key todecrypt the encrypted encoded media stream and present it to the client(see “Streaming phase” in FIG. 1).

A major problem in the scenario described above is that the viewer isexecuted on a host that is controlled by the client. Thus, the viewer isnot executed in the trusted environment 8 (where the movie 9 wasoriginally encrypted). There is, therefore, a risk that the client couldmodify the viewer. Even though the viewer will usually only decrypt anddecode part of the media stream, during the whole presentation processevery part of the encoded media stream will at some point be present inthe viewer memory-image. Another risk is that, since the memory image ofthe viewer has to contain the key, the user could extract the media key,in which case he would be able to create a copy of the unencryptedencoded media.

The problem of modification exists for purely software-based viewers aswell as for hardware-based viewers, for example, designated DVD players.Though it is more difficult to modify a hardware-based viewer than tomodify a software-based viewer, it is not impossible. Thus there existsa need for a system that addresses these drawbacks.

SUMMARY

General requirements for any effective protection mechanisms include thefollowing: It should be resource-intensive to break so that the cost ofbreaking is at least of the same magnitude as the value of the work. Anysuccessful attack should not be generalizable so that it can be appliedelsewhere. It should preferably also facilitate detection. The variousaspects of the invention described below address these requirementsindividually and the preferred forms of the invention provide a systemthat satisfies them all.

In the following discussion, a media work is a work that has a temporalaspect, i.e., it contains a number of presentational steps that have tobe performed in an appropriate order. The steps are normallycomputationally independent of each other and can be processedindependently. In most cases, the complete presentation takes asignificant amount of time: many minutes or some hours in the case of amovie.

According to one aspect of the invention there is provided a method oftransmitting a media work to a client comprising the steps of:

-   -   (a) encrypting the work using a sequence of different keys        corresponding to respective temporally spaced segments of the        work,    -   (b) securely transmitting a first key from a secure server to        the client and transmitting the corresponding segment from a        server to the client,    -   (c) in the client, using the first key to decrypt the        corresponding segment,    -   (d) in the viewer, presenting the decrypted portion,    -   (e) repeating steps (b) to (d) in respect of further segments        and keys.

The invention may be applied to any kind of media work (as definedabove) that has a temporal aspect, and is particularly useful fordistributing movies, for example streaming them over the Internet.

By dividing the document into a sequence of segments, it becomesimpracticable to copy more than a small part because each key candecrypt only one segment, i.e., the keys are functionally independent.Thus, only one segment of the movie at a time can be copied.Furthermore, there should not be a master key that can unlock otherkeys, i.e., the keys should preferably be structurally independent.Preferably, thousands of different keys are used for a typical length offilm such that each corresponds to a segment of a pre-determined length,e.g., of only a few seconds, say less than two or three seconds, andmost preferably a second or less. Most kinds of media works only havesignificant value if they are substantially complete. For example, amovie with only the last few minutes missing will usually be of littlevalue. Thus, someone seeking to illicitly copy a movie will have todecrypt each of the segments.

In order to maintain a continuous flow of data decryption, in someembodiments the client may ask for the current key and the next key(s)and cache a small number of keys (e.g., 2, 3, 4 or so) in memory.

Normally, the secure server is remote from the viewer, and is referredto herein as a ‘security server’.

The movie is generally encrypted in a trusted environment. Preferably,the keys generated during encryption are supplied to the securityserver, which is within the trusted provider environment. However,although the keys are then transmitted from the security server to theviewer, the movie or other work may be transmitted from elsewhere. Forexample, it may be streamed from a separate server that is outside thetrusted environment. Therefore, in one preferred embodiment, once themovie has been encrypted in the trusted provider environment, it is thensupplied to a non-secure streaming server.

Thus, in this arrangement, the client, which may be a software viewerprogram running on a remote computer (e.g., a user's PC) communicateswith a security server to receive the keys (referred to as media keys)and with a separate streaming server.

The media keys are preferably transmitted to the client following arequest from the client, and this is preferably done using a keyexchange protocol that makes use of a random data generator and thepublic key of the security server, which is known to the viewer.

In one implementation, when it is necessary to obtain the next mediakey, the client generates random data and encrypts it with the publickey of the security server. The encrypted data may then be included in arequest for the next media key, preferably with data identifying theclient, which is sent to the security server. When it receives therequest, the security server checks whether that client is entitled toreceive the media work, decrypts and extracts the random data andperforms a function using it and the requested key, to encrypt the keyusing the random data. In one embodiment, they may be XOR'ed. The resultis then sent back to the client. When the client receives the result, itcan then extract the requested key from the result by carrying out acorresponding function, for example by XORing it with the same randomdata that was provided in the original request for the key. In this waythe encrypted, encoded media stream can be decrypted without any secretkeys hidden in the source code of the viewer.

Preferably, the public key is included in the checksum calculation inorder to prevent a “man in the middle” attack in which the public key isexchanged.

In a preferred form of the protocol, steps are also taken to ensure thatthe client checked by the mobile guard is the same one as the onegenerating the random data. This may be done by extending the input tothe checksum to include the random data used to request the media key.Thus, the input to the checksum may include code from the client, thepublic key of the security server and the random data sent with the keyrequest.

As external entropy sources can be monitored, the entropy source usedfor generating the random numbers may be that generated by the executingenvironment itself in the form of how tasks are scheduled andinterrupted. Thus, the random generation process may consist of creatingseveral threads that work on different computational tasks that can beinput into a secure hash algorithm along with data from the currentstate of the viewer and the executing mobile guard.

The need for a continuing sequence of keys to be received by the clientcan be used to enforce user co-operation. Thus, if a certain steprequired by the provider is not carried out by the client, the supply ofkeys can be ceased. As will be discussed further below, this step may bean integrity check of the client, and preferably, the request for a newkey is only responded to when a so-called “mobile guard” indicates thatthe viewer is unmodified.

Where the mobile guard is employed, it is possible for it to generatethe random number used in the preferred key exchange protocol describedabove, rather than the actual client viewer/player program.

It will be appreciated that this enforcement of co-operation is possiblebecause the content provider controls the media work and because of thework's temporal nature, the work can be supplied in small parts with theuser being required to co-operate in order to receive subsequent parts.This is in contrast to conventional systems where a license unlocks thewhole document, effectively neutralising the temporal property.

In an alternative embodiment of the invention the trusted environment isextended so that the streaming server is included within it. When thisis done it is possible to have the streaming server generate media keysand encrypt the media stream on the fly. This ensures that each mediastream is encrypted with a unique set of media keys. That means that aleaked media key cannot be used to decrypt a different copy of the samemovie. To facilitate distribution of the media keys the streaming serversends them to the security server, which will distribute them to theviewer as described above. The downside is that another entity needs tobe trusted and that the encryption on the fly is computationallyexpensive. Thus, there is a trade off here between very high security onthe one side and complexity of the trusted environment and computationalcosts on the other side.

The invention is not limited to arrangements where the document isstreamed from a remote server. Because it is encrypted, the document canbe distributed in any convenient manner. Thus, the encrypted documentmay be provided to the client from a local server or on a physicalmedium (e.g., a DVD). The document may then be transmitted from thelocal server or physical medium to the viewer and decrypted in the samemanner as previously discussed.

Although this arrangement provides a significant improvement over theprior art system, there still remains the risk that the viewer could betampered with so that the decrypted work (movie etc.) could be recordedand copied. Thus, preferably, the invention further comprises means forchecking the integrity of the viewer to ensure that it has not beentampered with. This may be done by programming it to send a signal suchas a checksum to the security server at regular intervals, and/or when akey is requested. Such a signal would be designed to depend on the stateof the viewer so that any modification to the viewer would change thesignal.

However, there is a risk that such a measure could be overcome byprogramming the modified viewer to send the “correct” signal regardlessof its true state. Preferably, therefore, the method further requiresthat the security server interrogate the viewer using a number ofdifferent tests, which vary with time. In a particularly preferred form,the tests comprise the use of randomly generated algorithms which willonly return the correct result if the viewer is unmodified. Furthermore,failure to respond or an undue delay in responding can be taken as anindication of viewer modification.

Thus, preferably the security server is arranged to cease the supply ofkeys in the event that viewer modification is detected and/or if such aviewer integrity check is not successful.

The most preferred arrangement is for the algorithms to be transmittedby the security server to the client in the form of software code (e.g.,machine code). The software code may be termed a “mobile guard”, and isdescribed further herein.

Such a system of integrity checking is considered to be an inventiveconcept in its own right and therefore, viewed from a further aspect,there is provided a method of transmitting data to a client comprisingthe steps of:

-   -   (a) transmitting the data to the client,    -   (b) transmitting software code containing an algorithm from a        security server to the client, the algorithm having a result        that is a function of the state of the client,    -   (c) executing the code at the client,    -   (d) returning the result to the security server, and    -   (e) determining whether the result is indicative of an        unmodified viewer.

The data may be a media work that is streamed to the client, for exampleover the Internet, or it can be supplied from a local server, DVD orother media as discussed above. However, as will be discussed more fullybelow, it may be any kind of data that can be transmitted between serverand client. The client may be a program running on a computer or ahardware device such as a TV set-top box. The algorithm referred to instep (b) may be transmitted before any part of the document has beentransmitted, or the whole or part of the work may be transmitted beforethe algorithm. Preferably, the document is not viewed until after step(d) has been carried out.

Depending on the outcome in step (d), appropriate action can be taken.Where the work is being streamed, if the viewer is found to beunmodified, the transmission of the work and of any keys required todecrypt it would normally be allowed to continue. However, there may bea further step of (e) ceasing the transmission of the work and/or ofkeys necessary to decrypt it in the event that the result is notindicative of an unmodified client. Preferably, if no result is returnedfrom the mobile guard, this is also deemed to indicate that the clienthas been modified.

Where the work is being transmitted from a local source such as a localserver, DVD, etc. the action may be to cease the transmission of thekeys needed to decrypt the document.

Alternatively, other action may be taken if it is found that the clienthas been modified. For example, the transmission could be allowed tocontinue and evidence gathered to identify the user. This may beappropriate if it is desired to take legal or investigative action,e.g., to detect criminal activity or to prevent future illicit copyingof documents.

As noted above, the action taken in response to the identification of amodified client may be to cease transmission of decryption keys. It willtherefore be appreciated that the method may further comprise dividingthe work into a plurality of temporally spaced segments, which areencrypted using different keys. These keys may be distributed to theclient sequentially, and preferably as discussed above. Thus, if theirdistribution is ceased, the remaining part of the work cannot bedecrypted.

The method is preferably carried out using randomly generated secretalgorithms in the software code (as mentioned above). These so-calledenforcement algorithms generate a result that is dependent on the stateof the client (e.g., of a viewer program), but the correct result is notguessable by the user because of the random aspect. Preferably, theycontain a checksum calculation into which the viewer program's code isinput. Although the algorithm as a whole is secret, the checksumcalculation may be a known one such as the Message Digest Algorithm 5(MD5) (RFC1321 www.faqs.org/rfcs/rfc1321.html), which may be used incombination with randomized input modification.

Input modification refers to the random creation of a modifier thatpermutates the data that will be input into the checksum. In oneimplementation, when the software code (referred to here as a “mobileguard”) is generated, a random sequence is determined. When thealgorithm is executed, the input code from the viewer is divided into nblocks of the same size. These are then shuffled into theabove-mentioned random sequence and the result is then input into thechecksum algorithm. Although in this arrangement the checksum algorithmitself is public, its result is a function of the order in which the nblocks are input to it. This order is known to the security server andso the security server can determine whether the result returned to itindicates an intact viewer.

An alternative approach to creating an input-filtered checksum is todecompose a known checksum algorithm and reassemble it in a way thatreads the input in a given sequence.

Instead of using input filtering, it is possible to generate a checksumfunction from scratch. Thus the input can be split into/words (32 bits)and a function f is created that reads/words from the input and m wordsfrom a variable area that outputs a word. The function may comprise arandom number of assignments that are performed one after another andthe checksum may be the sum modulo 2³² of all the results of theapplication off.

Composing functions has the advantage that almost all code of thechecksum algorithm is randomly created, leading to more structuraldiversity in the code. Since the building blocks are quite small, itallows for easier interleaving with other algorithms.

The software code also preferably contains additional algorithms, whichmay be secret or non-secret. They are preferably functionally and/orspatially entangled with the secret algorithm. In this way the client'scomputer/viewer can be forced to carry out the additional algorithmsbecause if it does not the secret one will not be implemented. Theadditional algorithms may be used, for example, to check the integrityof viewer hardware.

As the mobile guard is present in the same environment as the viewer, itis potentially vulnerable to attacks. A user might try to modify it inorder to circumvent the protection methods it implements. Automatedattacks on it can be prevented by ensuring that the mobile guards arepartly randomly created, as discussed above. In addition, obfuscationtransformations may be applied to the mobile guards. The mobile guardmay hide the checksum in an opaque data structure that is interleavedwith the checksum in a way that is specific to the mobile guard.Variables may be located randomly in the mobile guard's memory and, inaddition, the mobile guard's instructions may be split into blocks,which are also located randomly in memory. This preferably includes theentry point into the mobile guard. Indeed, the entry point for onemobile guard can be provided by the previous one.

If these steps are carried out, a human attack then becomes necessary toovercome the obfuscation before any automated attack can commence. Suchan approach inevitably takes a significant amount of time and soprovided the “trust interval” between successive mobile guards issufficiently short, it will not be effective. In other words, becausethe mobile guards are replaced frequently, there is insufficient timefor this to be worthwhile. Thus, the obfuscation process protects themobile guard from tampering in the time interval before it is replacedby another mobile guard.

There is a risk of an observer spying on memory locations in a computerwhere the decrypted movie data is stored. If a known memory location isused then the data could be copied. Therefore, it is undesirable for itto be practicable to locate code by identifying a certain memorylocation (location-based identification) and preferably, once locationshave been used, they should not be re-used. Also, pattern-basedidentification—where code may be sought by looking for sequences likeMPEG headers—should preferably be prevented too.

The viewer is, therefore, preferably protected by the mobile guardagainst its state being determined by spying. To do this the mobileguard will preferably further comprise one or more protection algorithmsto protect against such attacks. This it may perform obfuscation taskson the client (e.g., on a viewer program), referred to hereinbelow as“runtime viewer obfuscation”, i.e., obfuscation is carried out on theviewer as it runs. This changes the memory image of the running viewer.

This runtime viewer obfuscation is considered a further inventiveconcept, and thus from another aspect, the invention provides a methodof obfuscating an executing viewer, comprising randomising the memoryimage of the executing viewer.

Runtime obfuscation may comprise one or more of the followingtechniques.

Code relocation comprises moving code blocks around in memory. As theprogram executes, the mobile guard will move the code to other parts ofmemory, which will then later be executed. This algorithm is preferablytightly interleaved with the checksum calculation.

Preferably, code relocation is implemented by (1) identifying all thebasic building blocks in the program and partitioning it into smallrelocatable segments; (2) during execution of the mobile guard thesesegments may be rearranged in memory to random locations; and (3)modifying all jump instructions to correspond to the new code locations.As a result, an attacker will be confronted by a memory image thatchanges during the execution of the mobile guard. Since the location ofthe segments is determined by the mobile guard provided by the securityserver, it is unpredictable to the attacker who cannot then rely on theassumption that certain memory locations contain certain data.

Data relocation comprises moving the data and changing the instructionsthat access it. Again, the new locations can be determined randomly.

Data hiding addresses the problem of location and pattern-basedidentification. One approach is to apply a two-way function to alter theappearance of the data—effectively to mask it. Preferably, a simpleone-time pad approach is used. It may comprise a newly created modulofunction that creates an index into an array of random data. The randomdata may be used to alter the sensitive data by applying the XORoperator between the random and sensitive parts. Preferably it isapplied between these and part of the address of the sensitive data.

One approach is to scramble (mask) and unscramble the data so thatsensitive data is stored in scrambled form, unscrambled when needed, andthen re-scrambled or deleted. However, this does leave a short windowwhen the data is unscrambled.

However, it is possible to take advantage of stream processing to delaythe unscrambling until the data is in the processor's registry.

Thus, the actual content decoder may be modified to perform the lastdecryption operation, as it needs new data. This means that there willnot be any decrypted data present in main memory at all. It may beprovided using the following steps:

-   -   a) The Mobile guard modifies the decoder to perform the last        decryption step as needed;    -   b) The next encrypted segment is obtained;    -   c) Media key for the encrypted segment is obtained;    -   d) The decryption stream is generated and placed in random        places in memory according to how the decoder was modified;    -   e) The decoder will then read a byte or a word at a time and        decrypt them as needed.

Code diversification comprises operations performed by the mobile guardon the client program during execution. The operations performed changethe code such that it consists of different instructions withoutchanging its semantics. This is to prevent pattern-based identification.One or more of the following steps may be carried out:

Context-independent instructions may be inserted. These are instructionswhose input context may be shared with contexts in the program but whoseoutput context is different from any input context in the program. Sincethey cannot alter any input context of the program, it does not matterwhat they process.

Context dependent instructions may be replaced by instructions thatperform the same function. It will be appreciated that this is moredifficult to achieve, but it is also more effective because they cannotbe identified by data-flow analysis.

Functional independent changes that can be made include changing theorder of execution of instructions, inserting instructions with orwithout temporary variables, re-ordering instructions in memory andmaking control flow changes.

Functional dependent changes require care in order to keep the functionand side effects intact. They include replacing instructions withfunctional equivalents, introducing identity functions, introducingoperators so that literal values are replaced by instructions thatinitialise the value arbitrarily and perform an operation that correctsthe value to match the original literal. Also, variables can beintroduced so that copies to a destination are replaced by copies of anewly created variable.

In an embodiment in which a hardware-based viewer solution is employed,for example a TV set-top box, the distributor of the viewer controls notonly the viewer software, but also the viewer environment, i.e., thehardware and operating system. Therefore, a hardware based viewer cangenerally be checked by a mobile guard in a much more complete mannerthan a purely software based solution. In this embodiment, the checksumalgorithm in the mobile guard is not restricted to checking the viewersoftware but can also check different aspects of the operating systemand the hardware.

Thus, the system can be used in two ways in connection withhardware-based viewers. Firstly, it can be used to replace solutionsthat are based on expensive tamper-proof hardware. Secondly, it canprovide additional security measures that come into play in the eventthat the tamper-proof hardware should be compromised.

It will be seen that the invention preferably relates to the combinationof individually encrypted segments of the document and the use of the“mobile guard” concept. Thus, viewed from a still further aspect, theinvention provides a method of transmitting a media work to a clientcomprising the steps of:

-   -   (a) encrypting the work using a sequence of different keys        corresponding to respective temporally spaced segments of the        work,    -   (b) transmitting software code containing an algorithm from a        security server to the client, the algorithm having a result        that is a function of the state of the client,    -   (c) executing the code at the client and returning the result to        the security server,    -   (d) determining whether the result is indicative of an        unmodified viewer,    -   (e) transmitting a segment from a server to the viewer,    -   (f) in the event that the result is indicative of an unmodified        viewer, securely streaming a key corresponding to the        transmitted segment from a secure remote server to the viewer,    -   (g) decrypting the segment using the key.

It will be appreciated that although the steps may be executed in theorder in which they are given above, at least some of the steps may beexecuted in a different order, or concurrently. For example, step (e)may be carried out concurrently with steps (b), (c), (d) or (f), suchthat the segments are transported before, with or after the keys.However the keys must be available before the segment is decrypted.

In one embodiment, the method comprises a further step (h) wherein steps(b) to (g) are repeated.

However, generally, the transmitted software code has a certain‘lifetime’ or ‘trust interval’, for example less than 30 seconds. On theother hand, segments are generally transmitted more frequently than thelifetime of the software code, for example one per second. As such, newsoftware code does not need to be transmitted each time a segment istransmitted, but will generally only need to be transmitted once thelifetime of the present software code has expired. Thus, steps (e) to(g) will generally be repeated until new software code is required, whenstep (b) will be repeated. In this way one piece of software code(mobile guard) protects the delivery of many keys.

Although the execution of the code and determination of whether theresult is indicative of an unmodified viewer (steps c and d) can be donemore than once for each piece of software code, generally, it will onlybe necessary to do it once during the lifetime of the software code. Assuch, steps (c) and (d) will generally only be repeated after step (b)has been repeated.

Viewed from a still further aspect, the invention provides a method oftransmitting a media work to a client comprising the steps of:

-   -   (a) encrypting the work using a sequence of different keys        corresponding to respective temporally spaced segments of the        work,    -   (b) transmitting software code containing an algorithm from a        security server to the client, the algorithm having a result        that is a function of the state of the client,    -   (c) executing the code at the client and returning the result to        the security server,    -   (d) determining whether the result is indicative of an        unmodified viewer, and further comprising the steps of:    -   (e) transmitting a segment from a server to the viewer,    -   (f) securely streaming a key corresponding to the transmitted        segment from a secure remote server to the viewer,    -   (g) decrypting the segment using the obtained media key,    -   (h) if step (d) indicates a modified viewer, preventing further        keys from being transmitted, otherwise repeating steps (e) to        (g).

Preferably, the method further comprises the step (i) of repeating steps(b) to (d).

It will be appreciated that although the steps may be executed in theorder in which they are given above, at least some of the steps may beexecuted in a different order, or concurrently. In fact, some steps maybe carried out more times than others.

Steps (b) to (d) can be carried out independently of steps (e) to (h),and are preferably carried out concurrently therewith. As mentionedpreviously, the software code generally has a lifetime that willencompass the sending of many segments and keys. As such, the repetitionof steps (b) to (d) (mentioned in step (i)) will generally be carriedout less frequently than the repetition of steps (e) to (g) (mentionedin step (h)). Preferably, step (i) is only carried out if the lifetimeof the software code has expired.

The invention also extends to apparatus configured to operate asdiscussed above, including a client configured to receive such streamedmedia and also the server arrangement, both in combination andseparately. Thus, from a still further aspect it may provide a systemfor delivering a media work to a client comprising:

-   -   (a) means for transmitting the work to the client,    -   (b) means for transmitting software code containing an algorithm        from a security server to the client, the algorithm having a        result that is a function of the state of the client, and    -   (c) means associated with the security server for receiving the        result and determining whether the result is indicative of an        unmodified client.

Another aspect provides a client, e.g., a viewer for playing a work suchas a movie, the client being arranged to: receive the work and toreceive software code containing an algorithm from a remote source; toexecute the algorithm on the client; and to return a result of thealgorithm to the remote source, thereby demonstrating the integrity ofthe client to the remote source and enabling the playing of thedocument.

The client preferably enables the playing of the work by decrypting it,or decrypting a segment of it using a key supplied to it by the remotesource. Preferably the client is configured to request a sequence ofkeys and uses the keys in sequence to decrypt consecutive sections ofthe work, which are then played as a continuous presentation.Preferably, as discussed above, the provision of keys is dependent onthe client demonstrating its integrity to the source.

The invention also extends to a combination of a system for deliveringworks as described above, in combination with a client, wherebydocuments are delivered to the client and can only be played if theviewer demonstrates its integrity to the source.

It will be seen that, in contrast to prior art software solutions, thepresent invention does not rely on secrets that are contained in thedata that is made available to the user, whether in the program code orin the media documents. It allows the early detection of copy attemptsand allows the content provider to initiate counter-measures before asubstantial part of the media document can be copied.

It has also been recognized that the concept of checking systemintegrity using a mobile guard has other applications beyond thetransmission of documents (as defined) to a client. It can be usedgenerally to verify the integrity and authenticity of code that is runin uncontrolled environments that perform calculations on input data. Itcan be used to prevent a party from changing the way that data isprocessed without this being detected. Thus, the discussion above inrelation to a media viewer can be applied to any client program.Applications include games, banking, audio, etc.

Thus, viewed from a still further aspect, the invention comprisestransmitting software code (such as a mobile guard) from a secure sourceto a client computer running a client program, the software codecomprising an algorithm having a result that is dependent on the stateof the client program, executing the software code and returning theresult to the source, whereby the source can determine the integrity ofthe client program. The invention also extends to apparatus arranged tooperate in accordance with such a method.

This aspect of the invention may employ any or all of the preferredfeatures discussed above, in particular concerning the mobile guard.References above to media works apply likewise to temporal payload datasent between server and client. Thus, the service provider can enforcethe cooperation of the user's client in the same manner and can withholdfurther payload data if either cooperation ceases or tampering isdetected.

Thus, it will be appreciated that any client that is in communicationwith a server can have its integrity checked on an on-going basis. Theinvention therefore allows a client that operates in an uncontrolledenvironment to be trusted. If it transpires that the integrity of aclient has been compromised then action can be taken. For example,communication with the client could be terminated, the provision ofdecryption keys suspended (as with the media streaming applicationsdiscussed above) and/or steps taken to gather evidence (e.g., in thecase of suspected fraudulent attacks on banking systems).

The invention is useful in the context of distributed calculationswhere, although confidentiality and dishonesty are not usually issues,the correct execution of software is. Thus, the mobile guard may be usedto protect against intentional or unintentional modification of theclient—both its software and, if required, hardware. Thus, the instancethat launches the distributed computing job can use mobile guards tocheck the correct operation of the clients at remote nodes that carryout calculations.

In the context of on-line gaming, modification of client programs canenable cheating which, if uncontrolled could cause customerdissatisfaction and lead to loss of revenue. The data concerned is notconfidential and there is little point in recording it (as with a mediawork), so it is normally sufficient to verify only the integrity of theclient software. Where the game operated on a client-server basis,mobile guards can be applied as discussed previously. If the user doesnot allow cooperation with the mobile guard then he can be refusedupdates on the global game-state.

In the case of home banking, mobile guards can be used to make sure thatthird parties do not access confidential data. While a normal user willnot normally be interested in modifying his client program, he may bethe victim of a man-in-the-middle attack. The banking server couldtherefore use a mobile guard to verify the integrity and authenticity ofthe home banking client and it may also contain the public key of thebanking server. This public key is used to encrypt all data that ispassed from the home banking client to the banking server and since theintegrity of the mobile guard is guaranteed, the user can be sure thathis data is kept confidential.

BRIEF DESCRIPTION OF THE DRAWINGS

Certain embodiments of the invention will now be described, by way ofexample only, with reference to the accompanying drawings:

FIG. 1 is a schematic drawing of a prior art media streaming system asdescribed above;

FIG. 2 is a schematic overview of a first embodiment of the invention;

FIG. 3 is a schematic diagram showing the components of a randomlygenerated checksum algorithm as used in the embodiment;

FIG. 4 is a flow chart showing the operation of the embodiment; and

FIG. 5 is a flow chart of the server algorithm employed in theembodiment.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

As may be seen from FIG. 2, a client is provided with a viewer 10 whichcan be used to view media (e.g., a movie) that is streamed from astreaming server 11 or alternatively from a local storage media, e.g.,CD 12. Each of these components of the system is outside the trustedenvironment 13. Within the trusted environment is the unencrypted movie14, a protection tool 15 to generate a protected movie 16 and a securityserver 17.

As in the prior art system illustrated in FIG. 1, the content ownerprotects the encoded media document, before it is delivered to theclient. However, instead of using a single media key, protection tool 15encrypts the movie with a very large number (thousands) of media keys20. This process yields an encrypted, encoded media, the protected movie16.

The media keys 20 are distributed so that they are spread out in time;during presentation of a media resource, they are securely streamed tothe client one at a time at intervals on request as will be describedbelow. The media itself is streamed separately. Each key comprises onlya few bytes (about sixteen) so the resources needed to stream the keyscreate a very low overhead.

Each key can be used to decrypt only about a second, or at most a fewseconds, of the movie so that obtaining only a single key is of littlevalue.

In the first embodiment of the invention, the protected movie isdelivered to the client in form of a data stream via path A, streamingserver 11 and media stream 18. In further embodiments, tangible media,e.g., a CD or DVD 12 are used.

The viewer 10 is executed on the client's host and is arranged toreceive the protected movie 16 from the streaming server 11 via mediastream 18 (or from the CD/DVD in other embodiments).During thepresentation process, the viewer 10 communicates with a security server17 to download the necessary media keys 20 to decrypt the protectedmovie 16.

In addition, the viewer 10 also downloads pieces of code called mobileguards 19 at regular intervals of about 30 seconds. These each haveembedded within them secret information in the form of an algorithm thatis created in the security server 17. The execution of these algorithmsis necessary to make use of the streamed data 18. When each mobile guard19 is transferred into the viewer it performs calculations determined bythe secret algorithm and returns the result to the security server. Themobile guard is structured in such a way that the result of thecalculation is only correct if the viewer has not been tampered with.The result of the secret algorithm contains a checksum that proves theintegrity of the viewer to the security server.

The mobile guard can also have other additional algorithms functionallyand spatially entangled with the secret algorithm. In this way theclient's computer/viewer can be forced to carry out the additionalalgorithms because if it does not the secret one will not beimplemented. In this way, the viewer may be fully checked.

If the result returned to the security server 17 by the mobile guarddoes not match the expected result, the security server stops thedistribution of the media keys 20 to the viewer. The same happens if theviewer 10 refuses a mobile guard or if the correct result does notarrive within a certain time. The key exchange protocol will beexplained in more detail later.

The secret algorithms are based on checksum calculations that have ahigh probability of detecting changes in the checked data (i.e., theviewer code). As may be seen from FIG. 3, a randomly generated checksumalgorithm 21 (for use in a mobile guard) uses a checksum calculationdivided into two steps: input modification 22, which is randomized, anda known checksum calculation 23 which is performed on the modifiedinput. These steps together make the randomized and secret checksumalgorithm.

Input modification refers to the random creation of a modifier thatpermutates the data that will be input into checksum calculation 23.When a mobile guard is generated by the security server, a randomsequence is determined. When the checksum algorithm 21 is executed bythe viewer, the input Program Code from the viewer is divided into nblocks of the same size. These are then shuffled into theabove-mentioned random sequence in the Input Modification stage 22. Theresult of this is then input into the Checksum Calculation stage 23.This uses the known Message Digest Algorithm (MD5). The checksumcalculation is then carried out and its result returned to the securityserver.

It will be appreciated that although the checksum algorithm itself ispublic, its result is a function of the order in which the n blocks areinput to it. This order is known to the security server and so thesecurity server can determine whether the result returned to itindicates an intact viewer.

The mobile guard needs to be protected against tampering and against thespying out of its inner workings. The first aspect of the protection ofthe mobile guard is to randomly create new versions each time a viewerneeds to be checked. Secondly the lifetime of the mobile guard in theviewer environment when it is being used is short (less than thirtyseconds). Although human (i.e., intelligent, as opposed to automated)attacks on the mobile guard are theoretically possible, they would takea significant amount of time. By having an expiration time of someseconds for each mobile guard, human-assisted attacks therefore becomevirtually impossible because the mobile guard is redundant long beforeany attack can be completed.

The mobile guard is obfuscated, as previously discussed, to defendagainst an automated attack.

The mobile guard randomises the memory image of the running viewer,referred to herein as ‘runtime viewer obfuscation’. Code and data areasof the viewer are swapped and the stack is scrambled. This is discussedmore fully below.

The effect of runtime viewer obfuscation is to make sure that onlyintellectual attacks can be performed on the runtime image of the viewerbecause it randomises and thereby hides the memory locations of thedecrypted, encoded stream.

In order to randomize the location of memory accesses, the mobile guardmodifies the structure of the viewer code and the data area. The codeand data area are split into logical segments. Care is taken thatsegment borders are not located inside opcodes.

After a newly downloaded mobile guard receives control and beforestarting with the decryption of the stream, the mobile guard relocatesthe segments to new positions. This process includes the modification ofcode segments—similar to relocation performed by dynamic linkers—to makesure that:

-   -   1. Jump- and Branch-instructions are transferring control to the        relocated positions.    -   2. Read- and Write-instruction are accessing the data at the        relocated positions.

After relocating the segments, the mobile guard performs its operationuntil it is replaced by the next mobile guard.

The mobile guard needs to know the entry points of certain functions inthe viewer. The new positions of the segments are known by the securityserver and provided to the mobile guard. In this way there is no need totransfer information between two mobile guards on the client side.

With regard to stack scrambling, the stack contains the return addressesto prior function calls. This can be used to either spy out control flowor to alter the control flow of the viewer by changing a return addresson the stack. In such an attack, when the program is about to jump backto the calling function, it could instead be transferring control topossible hostile code.

To protect the stack against such an attack, a method is used thatgradually scrambles the stack as new return addresses are added to it.The checked code will, after a function call, transfer control to ascramble function in the mobile guard, which scrambles the new returnaddress on the stack before returning control back to the callingfunction. To unscramble the stack a corresponding unscramble function inthe mobile guard is called before using any return address.

The implementation of the scramble function takes advantage of the factthat mobile guards are created as needed in order to check the viewer.This enables a unique scramble and unscramble function to be created ineach mobile guard. The scramble function basically consists of a set ofrandom data created by the security server and contained in the mobileguard that is XORed with the return addresses on the stack of theviewer. To select which part of the random data to use, a simplemathematical function is applied to compute an index into the set ofrandom data.

The viewer is therefore protected by the mobile guard against its state(including the position of the control flow and variable content) beingdetermined by spying (as discussed previously).

The media keys are transmitted at a rate of approximately one per secondto the viewer. This is done using a key exchange protocol that makes useof a random data generator and the public key of the security server,which is known to the viewer. When it is necessary to obtain the nextmedia key the viewer 10 generates sixteen bytes of random data andencrypts them with the public key of the security server 17. Theencrypted data is then included in a request for the key, which is sentto the security server.

The security server examines the request and only approves it if themobile guard indicates that everything is correct in the viewer. If themobile guard indicates that everything is fine, the security serverextracts the random data, XOR's it with the requested key and sends theresult back to the viewer.

When the viewer receives the result, it extracts the requested key fromthe result by XORing it with the same random data that was provided inthe original request for the key.

This protocol provides a way to decrypt the encrypted, encoded mediastream, without any secret keys hidden in the source code of the viewer.The lifetime of a key is a only few seconds, which prevents the securestreaming process from constituting a single point of failure in theevent of the extraction of one or a few secret keys.

It will be appreciated that there are effectively two separate threadsthat are carried out by the client and these are summarised in the flowchart of FIG. 4.

The first thread is verification. The client receives a mobile guard,which then verifies the client program. Once verification has beenconfirmed, a number n of keys can be received during the following trustinterval until the mobile guard expires. The thread must then berepeated with a new mobile guard.

Running in parallel to this is the presentation thread. For each key, asegment of the media stream is received decrypted and presented.

FIG. 5 summarises the operation of the server. On receiving a keyrequest, it sends a key to the client if, and only if, the mobile guardis still alive (i.e., if it is still within the trust interval of thatmobile guard). If the mobile guard has expired, a new mobile guard issent to the client and this is used to verify the client. If the resultis incorrect, the client is deemed to have been tampered with and keytransmission is then stopped. If the result is satisfactory, then a newtrust interval commences and during it the keys are sent to the client.

1. A method of transmitting a media work to a client comprising: (a)encrypting the work using a sequence of different keys corresponding torespective temporally spaced segments of the work; (b) securelytransmitting a first key from a secure server to the client andtransmitting the corresponding segment from a server to the client; (c)in the client, using the first key to decrypt the corresponding segment,(d) in the client, presenting the decrypted portion; and (e) repeatingsteps (b) to (d) in respect of further segments and keys, wherein thekeys are transmitted using a key exchange protocol that makes use of arandom data generator and the public key of the secure server, thepublic key being known to the client.
 2. The method as claimed in claim1, wherein the client encrypts random data generated by the random datagenerator with the public key of the secure server to create encrypteddata, and requests a key from the secure server, the encrypted databeing sent to the secure server with the request for the key.
 3. Themethod as claimed in claim 2, wherein the secure server decrypts andextracts the random data, and uses the random data to encrypt therequested key.
 4. The method as claimed in claim 3, wherein the secureserver performs a function using the random data in order to encrypt thekey.
 5. The method as claimed in claim 4, wherein the key and the randomdata are XOR'd.
 6. The method as claimed in claim 2, wherein theencrypted requested key is sent to the client and the client extractsthe requested key using the random data previously generated.
 7. Themethod as claimed in claim 2, wherein the client comprises the randomdata generator.
 8. The method as claimed in claim 2, wherein sixteenbytes of random data are used in each key request.
 9. The method asclaimed in claim 1, wherein the keys are delivered cryptographicallyindependently of each other such that no key can be used to decrypt morethan one segment.
 10. The method as claimed in claim 1, wherein keys areonly supplied following a check that the client is entitled to receivethe document.
 11. The method as claimed in claim 1, wherein each keycorresponds to a segment of a pre-determined length.
 12. The method asclaimed in claim 1, wherein the secure server is remote from the client.13. The method as claimed in claim 1, wherein the server and the secureserver are different servers.
 14. The method as claimed in claim 1,wherein the server and the secure server are the same server.
 15. Themethod as claimed in claim 1, wherein each key must be requestedindividually by the client.
 16. The method as claimed in claim 1,further comprising checking the integrity of the client to ensure thatthe client has not been tampered with.
 17. The method as claimed inclaim 16, wherein the secure server is arranged to cease the supply ofkeys in the event that either client modification is detected or if theclient integrity check is not successful.
 18. The method as claimed inclaim 16, wherein the integrity of the client is checked by softwarecode containing an algorithm which is transmitted from a security serverto the client.
 19. The method as claimed in claim 18, wherein each keyis transmitted only during a trust interval of the transmitted softwarecode that has successfully verified the integrity of the client.
 20. Themethod as claimed in claim 16, wherein checking the integrity of theclient comprises the use of randomly generated algorithms which willonly return the correct result if the client is unmodified.
 21. Themethod as claimed in claim 1, further comprising transmitting softwarecode containing an algorithm from a security server to the client, thealgorithm having a result that is a function of the state of the client,executing the code at the client, and determining whether the result isindicative of an unmodified client.
 22. The method as claimed in claim21, wherein the secure server and the security server are the sameserver.
 23. The method as claimed in claim 21, wherein the result isreturned to the security server.
 24. The method as claimed in claim 21,wherein keys are only transmitted if the result is indicative of anunmodified client.
 25. The method as claimed in claim 21, wherein thecode contains a checksum calculation into which program code of theclient and/or memory image of the client is input.
 26. The method asclaimed in claim 1, wherein the media work is streamed to the clientfrom a remote server.
 27. An apparatus configured to operate accordingto the method of claim
 1. 28. A system for transmitting a media work toa client, the system comprising: i) a protection tool arranged toencrypt the work using a sequence of different keys corresponding torespective temporally spaced segments of the work; ii) a secure serverarranged to a) transmit a first key to the client; iii) a serverarranged to b) transmit a first segment corresponding to the first keyto the client; and iv) a client arranged to c) receive the first key andthe first segment, decrypt the first segment using the first key, andpresent the decrypted portion; wherein the secure server, server andclient are arranged to carry out steps a), b) and c) for furthersegments and keys, and wherein the secure server is arranged to transmitthe keys using a key exchange protocol that makes use of a random datagenerator and the public key of the secure server, the public key beingknown to the client.
 29. A system for transmitting a media work to aclient, the system comprising: i) a secure server arranged to a)transmit a first key to the client, the first key being one of asequence of different keys with which temporally spaced segments of thework are encrypted; and ii) a server arranged to b) transmit a firstsegment corresponding to the first key to the client; wherein the secureserver and server are arranged to carry out steps a) and b) for furthersegments and keys, and wherein the secure server is arranged to transmitthe keys using a key exchange protocol that makes use of a random datagenerator and the public key of the secure server, the public key beingknown to the client.